The invention relates generally to computer network firewalls, and more particularly to a system, method and program to identify additional rules which may be needed by a firewall to permit messages with different combinations of source IP address, destination IP address, destination port, protocol, etc. to flow through the firewall.
There are different types of networks today. For example, there may be an intranet for local communications within an enterprise. It is presumed that all users of the intranet are trustworthy because they all work for the same enterprise. Therefore, usually there is relatively little security concern within the intranet. However, oftentimes users of the intranet want to communicate with another entity located on another network outside of the intranet. Because this other entity may not work for the enterprise, and this other network is not under control of the enterprise, this other entity and network cannot be thoroughly trusted. Therefore, a firewall may be installed at the gateway to the intranet. The firewall is responsible for enforcing a security policy for incoming communications. This security policy may define which types of networks that the intranet is permitted to communicate, what ports of what destination devices within the firewall are permitted to receive communications from what source devices and what protocols are permitted for the communications. The source and destination devices are identified by respective IP address. Each combination of source and destination IP address/protocol and port is called a “flow”, and the “rules” within the firewall specify what flows are permitted to pass through the firewall.
Typically, the rules specify combinations of source IP address, destination IP address, port, protocol, etc. of messages which are permitted to pass through the firewall. If a message arrives, and its combination of source IP address, destination IP address, port, protocol, etc. does not match a rule, then the message will be discarded and not forwarded to the specified destination. There are many reasons for discarding such messages. For example, they may originate from an untrusted/unsecure network, and the security policy of the destination network may prohibit all such incoming messages. Also, the message may be addressed to a port or use a protocol which is not supported in the destination network.
The most common protocols are TCP, UDP and ICMP. Each of these protocols includes additional criteria such as the range of ports used by TCP and UDP for certain types of requests, and the types and codes of ICMP. The TCP and UDP ports indicate which application in the recipient device should provide the requested services. It is also desirable in some cases to limit the range of ports for certain types of communications. The limitation on the range of ports facilitates the handling of the requested service. For example, many programs are written to open any available TCP or UDP port. This makes the identification of the application using such a port difficult. In some such cases it is possible to restrict the range of ports available to these applications to assist in identifying which application is using the port. Some types of firewalls have the ability to understand some applications that commonly open random ports, such as FTP, TFTP, H.323 etc. It may be preferable for some networks to not communicate with another network which uses a different range of TCP or UDP ports. Also, some networks may not wish to accept certain types of ICMP messages. For example, some destination networks may not wish to process “route redirect” messages as the device sending the “route redirect” may not be trusted. Furthermore, some protocols are more controllable than others. For example, TCP provides “handshaking” for every communication whereas UDP does not. So, TCP is more controllable than UDP and therefore it may be preferable for some networks to not accept UDP communications.
Different techniques have been used to determine if two networks, connected through firewalls or routers are authorized to communicate with each other, and which protocols including additional criteria are authorized for the communication. For example, if a systems administrator of an external network wants to communicate through its firewall or router to an enterprise behind the enterprise's firewall, the systems administrator of the external network can simply send its configuration information to a systems administrator for the enterprise. The configuration information may include the type of external network and the protocols it supports including the additional criteria for each protocol. Then, the systems administrator of the enterprise manually reviews the configuration information and determines if this external network should be permitted to communicate with the enterprise through the enterprise's firewall and if so, what IP protocol to use. If the system administrator believes the requested flow is acceptable according to the enterprise's policy, the systems administrator updates a rule file in the firewall of the enterprise to permit it to communicate with the external network with a specified IP protocol including additional criteria. Likewise, the systems administrator of the external network will update a rule file in its firewall or router to permit it to receive communications from the enterprise's network with a specified IP protocol including additional criteria.
Usually at least once a year, all the firewall rules are verified to ensure they still conform to the company policy. Traditionally this is completed manually by the systems administrator, or a person outside of the day-to-day operations of the firewall such as a security administrator. The systems administrator or security administrator reviews each firewall rule to confirm the network type of each IP address and ensures that the flows configured in the firewall are acceptable according to the company policy. While this technique is effective, it requires tedious, human review of the configuration information from each network with which communication is desired, and there can be many such networks. Also, it focusses on checking permissibility of specified communications, rather than determining all potential permitted communications. Also, routers and firewalls of networks are often changed, and this may require the foregoing interaction between the systems administrator or security administrator to be repeated.
There is another technique to determine if two networks, connected through firewalls or routers are authorized to communicate with each other, and which protocols (including additional criteria) are authorized for the communication. According to this technique, a packet generator is located inside the firewall or router of an originating network being checked for compatibility with other networks. The packet generator sends a set of communication packets onto the network, but preferably to an unoccupied IP address. The communication packets of each set have different IP protocols with different additional criteria, but ones that the originating network supports. A “sniffer” is located just outside the firewall or router of the originating network and logs the generated packets that are allowed to pass through the firewall or router of the originating network. Based on the presence or absence of the original packet being logged by the “sniffer” a report can be generated as to what traffic the firewall or router allows through. This report can then be compared with the corporate security standards. While this technique is partially automated, it burdens the networks with many communication packets to handle. Also, it does not consider the type of destination network as a criteria in determining whether the originating network should permit communication; this is still left as a manual task once the report has been manually generated. The other concern is that the corporate security standards often change.
It was also known that if a message packet does not reach its intended destination, the source computer that sent the message packet would learn of this, via some type of return code or the absence of a response altogether. Then, the user of the source computer would alert a firewall administrator for the network of the intended destination to investigate the problem. In response, the firewall administrator would investigate the reason that the message packet did not reach its intended destination. The firewall administrator would check if each firewall in the path from the source computer to the destination device included a rule that permitted the flow. If all the firewalls do not include the requisite rule, then the firewall administrator would add the rule if the firewall administrator knew it was valid, or ask the owner of the network of the destination device to determine if the rule should be added to the firewall, and if so, open a request to create and add the rule. If all the firewalls in the path have a rule that permits this flow, but the message packet did not reach its intended destination, then the firewall administrator would check communication linkages to determine whether a logical of physical network connection is configured or connected. If during the course of this path verification the message packet is recorded, usually by use of a sniffer, on the logical destination network, the firewall administrator would scan the destination system to determine if the intended destination port is open. The administrator scanned the destination port using a known tool which generates a test packet and sends it to the destination port. The tool then checks for a response indicating that the port is open. If the port is not open, the administrator would check the contract with or query the owner of the destination device to determine if the port should be open. If so, the administrator would open the port.
A general object of the present invention is to identify additional rules which may be needed by a firewall to permit messages with different combinations of source IP address, destination IP address, destination port, protocol, etc. to flow through the firewall.
A more specific object of the present invention is to provide a technique of the foregoing type which is at least partially automated.